Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

The Watch window shows the values of watched variables whenever the program stops. Figure 14.2 shows the Watch window attached to the Immediate window. In this example, the variable x has the value 0. The statement ?x in the Immediate window made Visual Basic display the value there as well as in the Watch window.

Figure 14.2  The Watch and Immediate windows.

Figure 14.3  Watching for a condition.

You can right-click on the Watch window to display a popup menu allowing you to add, edit, or delete watches. When you edit a watch, Visual Basic displays a dialog like the one shown in Figure 14.3. Using this dialog, you can modify the value Visual Basic displays. If you click the Break When Value Changes option, Visual Basic will stop the program when the variable’s value changes. If you click the Break When Value Is True option, the program will stop when the watch expression is True.

Figure 14.3 shows the watch editing dialog preparing a watch expression. In this example, the program will stop whenever the condition (i > j) And (value(i) < 1000) is True. Watch expressions like this one can make finding bugs much easier. If you know a variable is being set to an incorrect value, enter a Boolean expression that says the variable has that value in the watch window. Then run and let the program stop when the variable is set.

Modify Variables

The Immediate window allows you to modify values in addition to displaying them. Simply enter the variable name, an equals sign, and the variable’s new value. Then press the carriage return key. For instance, the following line of code sets the variable X to the value 1324.

X = 1324

Assignments in the Immediate window can include the values of other variables and even function return values. The following statement sets entry number i in the day_name array to the current day’s name (Monday, Tuesday, etc.).

day_name(i) = Format$(Date, "dddd")

Use Ctrl-F9

While running code in the debugger, you can click on a line of code and press Ctrl-F9 to make control jump to that line. This is a remarkably powerful feature provided by few other development environments. It allows you to quickly test different paths through a routine. Test one path. Then use Ctrl-F9 to jump back to the beginning of the routine to test another path.

Sometimes it is hard to make an If statement’s condition have the value you want. In that case, you can use Ctrl-F9 to jump into the right part of the If statement’s code to see what would happen if the condition has the proper value.

You can even use Ctrl-F9 to skip certain specific statements or jump out of loops. Use caution when you jump into a loop, however. If you jump into the middle of a For loop, the value of the control variable and the loop’s status is unclear. For example, suppose when the following code stops, you use Ctrl-F9 to jump to the Debug statement. Visual Basic executes Debug.Print with the variable i set to 0, and then ends the For loop. This is probably not what you would expect. The moral is to jump into loops cautiously or not at all.

Private Sub BadJump()
Dim i As Integer

    Stop                           ' Stop here.
    For i = 1 To 10
        Debug.Print i              ' Use Ctrl-F9 to jump to here.
    Next i
End Sub

Examine Decision Statements

Decision statements determine the path of execution that the program follows. Decisions made by If and Select statements are more likely to send the program off course than simple calculations are. Because they may mark the beginning of a bad decision, you should pay special attention to If statements while you are testing.

For and While loops make decisions implicitly. Every time the program passes through a loop, it evaluates the loop’s stopping conditions to see if it should stop. The logic used by these tests can be confusing, particularly if the code uses Exit statements to break out of the middle of the loop.

As you test a routine, concentrate on the statements that make decisions. Exercise all of the possible decision results so you follow each possible path of execution.

Anticipate Outputs

Some programmers begin a test and then look at the results. If they do not know what to expect, they are likely to convince themselves that the results look correct even if they are not.

Before you begin a test, know what outputs to expect. Compare your predicted outputs with the actual results carefully. If there is a discrepancy, figure out why. Sometimes you will have a simple difference in formatting. Be absolutely certain that is all that is wrong before you declare the results correct. It is easy to convince yourself that a small difference is unimportant when actually a bug is at work.

Fake Errors

Use the Err.Raise statement to simulate error conditions and test a routine’s error handling. Test obvious errors such as division by zero (11) in arithmetic expressions and file not found (53). Also test some errors that are unlikely to occur, such as out of memory (7) and object already loaded (360).

If a routine calls other routines or library functions, or uses control properties, simulate errors in those calls. For example, the GetStockObject API function returns 0 if it fails. If a routine uses this function, you should execute the code until you get to the call to GetStockObject. Use Ctrl-F9 to skip that statement and then use the Immediate window to set the return value to 0 to simulate an error.

    :
' Set a break point on the following line.
brush_handle = GetStockObject(BLACK_BRUSH)

' Skip to the following line and set
' brush_handle = 0 in the Immediate window.
If brush_handle = 0 Then
    ' Error getting the brush handle.
        :

Find Your Own Bugs

Many development projects use separate testers to look for bugs in the code. Part of the reason for having separate testers is that they do not know the code as intimately as the developers do. Because they are unfamiliar with the code’s internals, they do not have preconceptions that might stop them from finding cases the code cannot handle. They will hopefully try things the developers will not think of because the developers know what inputs the code expects.

On the other hand, testers cannot design test cases specifically designed to uncover problems in the code. Because they do not understand the code, they cannot perform white box tests. If you wrote a routine, only you understand it well enough to effectively run white box tests.

A tester who finds a bug knows very little about where the bug is or exactly what the problem might be. All he can tell you is that an error occurred. On the other hand, when you find a bug in your own routine, you can usually locate it relatively quickly.

For example, suppose you are building an application that dispatches firefighters. A tester might be able to tell you that the program dispatched a supervisor to a simulated sulfuric acid spill when it should have dispatched a hazardous materials unit. This tells you very little about the cause and location of the error.

On the other hand, suppose you have just finished writing the code that determines which units have the skills to work a particular incident. If you test the routine thoroughly, you may discover that the routine incorrectly gives supervisors every skill. Now you know precisely where the bug is and you can fix it easily.